This section describes the basic features of Xtend IVR script language. For detailed information about the commands and their syntax please refer Commands and Functions. The language consists of Internal Commands, Loop Statements, Conditional Statements, Arithmetic Expressions, Unconditional Jumps, Plugins and External Program Execution.
Internal Commands
Internal Commands are those commands, which are implemented internally by the Xtend IVR engine. To use these commands the user is not required to install any additional Plugins. For more information about the internal command set supported by the Xtend IVR engine, please refer Language Reference. There are some built-in functions available for string manipulation and for character conversion. In addition, the language supports user-defined functions also.(For more information refer Plugins)
Loop Statements
The only loop statement currently supported by the script is the WHILE... ENDWHILE. You can nest any number of WHILE...ENDWHILE inside another WHILE...ENDWHILE statement. You can break out of an infinite loop by calling the BREAK command or by using the GOTO command.
Conditional Statements
Currently the language supports two variants of IF statements.
IF...THEN GOTO
First one is used to jump directly to a label specified after the THEN clause.
Second type is used to execute a block of code inserted inside the IF...ELSE...ENDIF
clause.Third one which represents the IF...ELSEIF ladder executes the
block which succeeds the IF, ELSEIF or ELSE condition.
IF…ENDIF, IF...ELSE...ENDIF , IF…ELSEIF...ENDIF.
Arithmetic Expressions
Language supports any valid arithmetic expressions for
Addition,
Subtraction,
Multiplication
and Division such as:
$a = $a + $b
$a = $a+ $b * $c
Arithmetic operations are permitted only on numerical values. For more information
please refer Language Reference.
Unconditional Jumps
You
can use the GOTO command to unconditionally
jump to another statement. GOTO can be used anywhere and at any time.
That means you can even use it inside a WHILE...ENDWHILE loop
to break from the loop.
There are two methods by which we can execute an external application from the Xtend IVR script. First method is to use the RUN command, which is the recommended method and is discussed in more detail at the Executing External Programs. The second method is called the Plugin mechanism.
Commands, which are not documented as an internal command, can be called as Plugins. That means if you mistype an internal command, the script parser will report that the specified Plugin was not found. The engine will search for the Plugins under the Plugins directory and if not found would report an error.
The syntax for a Plugin and a RUN command is different. The difference lies in how the parameters are passed to the external application and how the status values are returned to the script. Under a RUN command it is the responsibility of the developer to pass the $VarFile as one of the parameters. But in the case of Plugins the Xtend IVR Engine will automatically pass $VarFile as the first parameter. This parameter is hidden from the developer. So whatever parameters the user passes, it will all come after the first hidden parameter which is the $VarFile. Hidden in the sense that it is automatically passed by the Xtend IVR Engine. Plugins can also take the syntax of a function call.
Example
Lets see how a Plugin can be used inside a script.
MsgBox(”Hello”)
The above
example shows how to use the MsgBox Plugin,
which is shipped with the Xtend IVR Toolkit. The first example
uses the most common syntax. The second example shows the Plugin
as a function call. There are some reserved variables used only by the
Plugins.
They all start with the $Plugin key word. These variables
are
$PluginReturn
$PluginParamCount
$PluginParam1
$PluginParam2
$PluginParam3
…
…
…
If you are using the Plugin on the right side of an assignment expression you should always set the variable $PluginReturn to the value you are returning from the Plugin. Xtend IVR Engine will automatically copy the contents of the $PluginReturn to the variable on the left side of the assignment expression.
Example
$a = SomePlugin $param1 $param2
$a = SomePlugin($Param1,$Param2)
In the above example variable $a is assigned the value found in the variable $PluginReturn after the Plugin, SomePlugin, is executed.
$PluginParamCount contains the number of parameters passed to the Plugin. In the above example $PluginParamCount variable will contain the value two.
Xtend IVR Engine will automatically copy the Plugin parameters to the variables $PluginParam1, $PluginParam2, …, $PluginParamN, where N is the last parameter in the sequence. You can also retrieve these parameter values as run time arguments inside your Plugin module. But the first parameter will always be the value of the $VarFile. In the above example $PluginParam1 will contain the value of $Param1 and $PluginParam2 will contain the value of $Param2.
Executing External Programs
This is the mechanism by which the developers can integrate their module with the Xtend IVR. You invoke an external program by using the RUN command. The RUN command takes multiple parameters. But the first parameter should always be the executable program.
RUN "sample.exe" $VarFile
Where sample.exe is the executable program developed by you. If you don’t give the absolute path, Xtend IVR assumes that the module is residing inside the script directory (Directory where the script (.dt) file was loaded from). If the module is not found in that directory, Xtend IVR engine will report an error. Suppose you wish to execute a Java class, then the command you should give is given below....
RUN "c: \ jdk1.2 \ bin \ java.exe myclass.class" $VarFile
Another variant of the RUN command is available which has got a different syntax. It is given below ...
! "c: \ jdk1.2 \ bin \ java.exe myclass.class" $VarFile
Both mean the same thing. Except that the latter starts with an "!" (For Clipper, dBase and Foxpro programmers, this would not come as a surprise). Now an important question arises as to how does Xtend IVR communicate with the external program? The answer is through the $VarFile. When the Xtend IVR engine finds a RUN command, it will create a temporary file and dump all active variables and their values to this file. The reserved variable $VarFile contains this file name and an external program can open this file and read all the variables and their values. They can change the values within the module and can re-write to the same file before they exit. The Xtend IVR engine will re-read this file and will update the active variables. You can also introduce new variables by appending the variable and its value to this temporary variable file. This temporary variable file is written in a special format and the user has to be careful when modifying the file. The contents of a sample temporary file are given below.
$VarFile temp\0.var
$ScriptFile test.dt
$DeviceId 0
$RecordFile temp\0.rec
$Ring 1
$ExitCode 0
$Error Unable to open Data File
$RETRY 1000
$Date 02/03/2000
$Time 11:00:40
$Timeout 0
$HallTicketNo 12345
$Sample c: \ ivr \ sample.mdb ; ADDRESS ; ; ; MDB
As you can see every line begins with a "$" sign followed by
the actual variable name then a space and finally the value of the variable.
Variables and their values are defined in a single line, which means that,
there should not be any new line character within the variable definition
other than the line separator. There should not be any empty line in between
two variables. If there is any empty line then the Xtend IVR
engine will take it as the end of the variable list. The Xtend IVR
engine will ignore everything below that empty line.
* Every variable should start with a "$" sign.
There are some variables pre-defined (Reserved variables)
by the Xtend IVR, which the user should not modify. These variables
are modified by the Xtend IVR itself and contain information
regarding the origin of the call and the state of execution of the script.
These variables are...
* Value of the variable should be in a single line. If the value
overlaps to the
second line, the Xtend IVR engine will ignore the overlapped value.
* Variable name should not contain any spaces.
* Variable name containing a "." has special meaning and should
be avoided.
Remarks
Developers are advised to use the RUN command for executing an external module. The Plugin concept is introduced for adding additional functionality like Database Access, Debug Support etc.
If the plugin return value is non zero then the execution will automatically jump to the ONSYSTEMERROR label.